iT邦幫忙

2026 iThome 鐵人賽

DAY 27
0
AI 自動化

《從聊天到規格書:我如何把 AI 訓練成報告產線員工》系列 第 27

【Day 27】串接常見的辦公軟體:將報告自動推送到 Slack / Teams 或 Email

  • 分享至 

  • xImage
  •  

前言
昨天我們寫出的腳本,最後一步是把報告存成本機的 .md 檔案。但如果報告存在你的電腦裡,還是得靠你手動打開、上傳、或轉發給主管——這個環節,依然是一個需要人工介入的「最後一哩路」。今天要把這一哩路也自動化,讓報告產出後,直接送到該去的地方。

一、為什麼「自動推送」是自動化流程真正的終點
回顧 Day 1 拆解「寫報告」的三步驟(收集資料、判斷整理、排版),我們其實漏講了一個隱藏的第四步:送出報告。如果前三步都自動化了,唯獨這一步還要你手動做,你的「自動化」其實只完成了大半,每週依然需要記得「去把檔案傳出去」——而人是會忘記、會請假、會來不及的,這正是自動化原本想解決的問題。
二、常見的推送管道,分別適合什麼情境
延續昨天的程式邏輯,今天示範三種常見的推送方式,你可以依照公司實際使用的工具挑選:

  1. Slack / Teams(即時通訊)
    適合需要「發出去就會被立刻看到」的場景,例如週報發布後,團隊隨時可以在頻道裡討論。大多數即時通訊軟體,都提供類似「Webhook」的機制——這是一種特化的 API,專門設計成「把一段訊息,自動貼進某個頻道」用的,串接起來通常比一般 API 更單純:

python
import requests

def send_to_slack(content, webhook_url):
payload = {'text': content}
response = requests.post(webhook_url, json=payload)
response.raise_for_status()
2. Email(電子郵件)
適合需要正式紀錄、或收件對象習慣用信箱管理工作的場景(例如稽核單位可能更習慣收到正式郵件,而非即時通訊訊息)。Python 可以透過內建的 smtplib 模組寄送郵件:

python
import smtplib
from email.mime.text import MIMEText

def send_email(content, subject, to_address, smtp_config):
msg = MIMEText(content)
msg['Subject'] = subject
msg['To'] = to_address

with smtplib.SMTP(smtp_config['host'], smtp_config['port']) as server:
    server.starttls()
    server.login(smtp_config['user'], smtp_config['password'])
    server.send_message(msg)
  1. 兩者並行
    實務上,很多團隊會選擇「Slack/Teams 發即時通知,Email 留存正式紀錄」——這不衝突,你可以在同一段程式裡,把昨天產出的報告,同時送往兩個管道。
    三、串接時容易忽略的細節:格式轉換
    這裡有個實務上常被忽略的小陷阱:Markdown 格式,在不同平台的顯示方式不一定相同。 你辛苦設計的 # 標題、- 條列符號,在 Slack 或 Teams 裡,不一定會被正確渲染成排版後的樣子——有些平台有自己的訊息格式規範,直接貼 Markdown 語法進去,可能會變成一堆看起來很奇怪的符號堆疊,而不是你預期的排版效果。
    建議做法:在推送到不同平台之前,先確認該平台實際支援的格式語法,必要時寫一段簡單的轉換函式,把標準 Markdown 轉成該平台認得的格式,而不是假設「反正都是文字,應該哪裡都能用」。
    四、推送失敗時,不能悄悄放過
    延續昨天談過的錯誤處理概念,推送這一步特別需要注意:如果推送失敗(網路問題、Webhook 網址失效、Email 帳密錯誤),絕對不能讓程式安靜地結束、假裝一切正常。 至少要做到:
  • 推送失敗時,程式明確記錄錯誤訊息(例如寫進一份簡單的錯誤日誌)
  • 有辦法讓你(人)在合理時間內發現「這週的報告沒有送出去」,而不是等到主管來問「這週報告呢」才發現問題
    這也呼應 Day 12 談過的「安全降落」精神——自動化系統遇到問題時,該做的是明確暴露問題,而不是悄悄失敗、讓人誤以為一切正常。
    五、今天的行動練習
    確認你們團隊實際使用的溝通工具(Slack、Teams,或其他),查詢該工具是否提供 Webhook 或類似的簡易串接方式(通常在該工具的管理後台或技術文件裡可以找到設定方法)。如果暫時沒有正式串接的權限,可以先用 Email 的方式做一次簡單測試,確認自己的腳本邏輯正確。

小結
今天我們把自動化流程,從「產出報告」延伸到真正的「送達報告」——這才是完整走完了 Day 1 一開始拆解出來的整個工作循環。記得留意跨平台的格式相容問題,也別讓推送失敗這件事悄悄溜走沒被發現。
明天,我們要退後一步,不再寫程式碼,而是用一張圖,把整個自動化系統的架構,清楚地畫出來。


上一篇
【Day 26】Python 自動化串接:寫一個簡單腳本讀取 CSV 並打 API
系列文
《從聊天到規格書:我如何把 AI 訓練成報告產線員工》27
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言